Columbia Kermit/kermit.zip/newsgroups/misc.19980901-19981211/000191_news@newsmaster….columbia.edu _Fri Oct 23 00:29:09 1998.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id AAA08826
    for <[e-mail]>; Fri, 23 Oct 1998 00:29:09 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA12951
    for kermit.misc@watsun; Fri, 23 Oct 1998 00:29:08 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!jaltman
From: [e-mail] (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?
Date: 23 Oct 1998 04:29:06 GMT
Organization: Columbia University
Lines: 86
Message-ID: <70p0mi$nij$[e-mail]>
References: <[e-mail]> <[e-mail]> <70ofhk$e9d$[e-mail]> <[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9387

In article <[e-mail]>, Joe Doupnik <[e-mail]> wrote:
:     It is the very same thing we talked about. Please notice that I am
: not critisizing K95 et al, but I am blasting the IETF for letting things
: progress has they have. You nicely made my point by showing that some apps
: which expect a certain terminal type recognize things are not working and
: they don't work either. That is proper. Now the user has the opportunity
: to do something specific about the matter, rather than being deceived
: by Telnet Options. Some apps don't know and then we are in difficulties
: without realizing it.
:     Life would have been simpler if there had been both adherence to
: the list of terminal names and timely expansion of the same, and vendors
: who read before pressing keys. But like Unix itself, things got out of
: control irreversibly.
:         Given the muddle my position remains: what the user selects is
: what he/she expects to receive. Telnet terminal kind is only one piece
: of a larger integrated sequence of actions and it cannot change its
: behavior willy nilly without bad consequences.
:     What can be done? Well, there is a constructive alternative
: available to us. One, enable both ends to deal with aliases of common
: terminal names. Two, allow different terminal kinds upon permission and
: control of the user. The first is readily accomplished in many cases, the
: second requires user interface modification.
:     Joe D.

There are two very different philosophies about how things should be
handled when the software configuration does not match the
requirements of the connection the user wants to make.  The first,
which is your approach, is to not do anything and wait for the user to
detect the problem and initiate a fix.  This approach makes the very
big assumption that the user will know how to determine what is wrong
and be able to fix it, or have someone locally available to do that
for them.

The second approach is to try to fix it for the user in an automated
way before the problem becomes a reality.  Very often this approach
works, and the user doesn't even know the difference.  Sometimes it
doesn't work at all and the user who knows how to fix it does, and the
ones that do not know, ask for help.  Sometimes it sort of works and
the response of the user (see previous sentence) depends upon on the
impact of the new problem.

I am a believer in the second approach.  And hence, the software that
I create tries to do things for the user whenver possible even if
sometimes we might guess wrong.  We always provide a method for the user
to turn off the automatic mode if it is necessary.  Hence, Kermit 95
and C-Kermit (when possible):

 . auto-detect file transfers in both directions
 . configures character-sets for Text transfers and terminal emulation
 . sets the terminal window size
 . responds to escape sequences during the INPUT command so the user
   does not have to worry about them
 . auto-switches between terminal types
 . optimizes file transfer parameters
 . auto-switches between file transfer modes based upon filename
 . automates the authentication process
 . auto-detects the modem type associated with a TAPI device
 . auto-detects the current location for dialing local, long
   distance, international calls.

My experience has been that as the end user population becomes more
mainstream and less techie we must attempt to automatically adjust
to the technical necessities of the moment for the user whenever
possible.  Otherwise, one of two things happen:

 . the user base overwhelms the support personel with questions
   about why won't the modem dial, or PINE start, or the file
   transfer go fast; or

 . the user becomes frustrated and chooses another product.

Given the low volume of technical support queries that we receive
compared to our installed base, I think that we have made the
correct set of choices.

Does this approach work all of the time?  No, but for every time
is does work, we have one less user making a phone call, sending
an e-mail or posting to a newsgroup.  And I think that is
appreciated by our users and their local support groups.



    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [e-mail]